Web sites, or Internet sites, very often provide information, products, services, or the like to their users. Many web sites require users to “register” before their web servers will grant access to the users. During registration, a user typically supplies personal information such as username, account number, address, telephone number, e-mail address, computer platform, age, gender, and/or hobbies to the registering web site. The registration information may be necessary to complete transactions (e.g., commercial or financial transactions). Typically, the information also permits the web site to contact the user directly (e.g., via e-mail) to announce, for example, special promotions, new products, or new web site features. Additionally, web sites often collect user information so web site operators can better target future marketing activities or adjust the content provided by the sites.
When registering a user for the first time, a web site typically requests that the user select a login ID and an associated password. The login ID allows the web site to identify the user and retrieve the user's information during subsequent user visits to the web site. Generally, the login ID must be unique to the web site such that no two users have the same login ID. The password associated with the login ID allows the web site to authenticate the user during subsequent visits to the web site. The password also prevents others (who do not know the password) from accessing the web site using the user's login ID. This password protection is particularly important if the web site stores private or confidential information about the user, such as financial information or medical records.
If the user visits several different web sites, each web site may require entry of similar registration information about the user, such as the user's name, mailing address, and e-mail address. This repeated entry of identical data is tedious when visiting multiple web sites in a short period of time. Many web sites require the user to register before accessing any information provided on the site. Thus, the user must first enter the requested registration information before he or she can determine whether the site contains any information of interest.
After registering with multiple web sites, the user must remember the specific login ID and password used with each web site or other Internet service. Without the correct login ID and password, the user must re-enter the registration information. A particular user is likely to have different login IDs and associated passwords on different web sites. For example, a user named Bob Smith may select “smith” as his login ID for a particular site. If the site already has a user with a login ID of “smith” or requires a login ID of at least six characters, then the user must select a different login ID. After registering at numerous web sites, Bob Smith may have a collection of different login IDs, such as: smith, smith1, bsmith, smithb, bobsmith, bob_smith, and smithbob. Further, different passwords may be associated with different login IDs due to differing password requirements of the different web sites (e.g., password length requirements or a requirement that each password include at least one numeric character and/or at least one uppercase character). Thus, Bob Smith must maintain a list of web sites, login IDs, and associated passwords for all sites that he visits regularly.
Although presently available multi-site user authentication systems permit a web user to maintain a single login ID (and associated password) for accessing multiple, affiliated web servers or services, further improvements are desired. For example, authentication data is typically sensitive in nature and should be protected. Thus, maintaining security between numerous affiliate web servers and the authentication server performing the authentication function is important.
Presently available network authentication protocols, such as Kerberos authentication, employ a shared or single key for authenticating the identity of users attempting to log on to a network and for encrypting their communications. The use of a shared key, sometimes referred to as symmetric key encryption, requires a key provisioning process for a new web service to utilize authentication services. In a Kerberos system, the authentication server (i.e., the Kerberos server, or key distribution center (KDC)) must distribute the shared key to every affiliate server using its authentication services and must refresh the key regularly. The KDC often issues the key by postal mail. Unfortunately, the need to provide the shared key introduces significant complexity in signing up new web services and conducting ongoing maintenance (e.g., periodical key revisions). Moreover, in a federated environment involving multiple authentication service providers, key distribution becomes even more complicated.
Key distribution is further complicated when an affiliate site decides to accept a “kerb” ticket from two or more independent KDCs. Also, the key for the affiliate must be configured in both KDCs. In other words, the more KDCs that an affiliate site supports, the more complex the key distribution process. In addition, if KDCs federate with each other, they must all share keys, again adding key distribution complexity.
Keys are also at risk of being stolen at either the KDC or at one of the affiliate sites, which presents a danger of key compromise at either end of the security protocol. For instance, a human break-in at the authentication service can potentially steal all of the keys for every affiliate server. This would essentially shut down the authentication service because of the time needed to revise all of the keys across the entire network of affiliated servers.
A public key infrastructure (PKI) may also be used to support encryption as well as digital signatures. Public key encryption employs dual keys, i.e., one public key and one private key. Data encrypted by the public key can only be decrypted by the private key, and vice versa. Although PKI provides a useful protocol for authenticating and digitally signing documents, it does not perform well in a scalable/cross-platform authentication system. For example, a PKI system operates too slowly when handling large amounts of data because it generally requires much longer keys (typically, 512 bits and above, whereas a shared key uses less than 200 bits). The longer the key, the more computation power is required to encrypt and decrypt.
Moreover, PKI requires that keys be synchronized. PKI has two keys (public key and private key) and these two keys must stay in sync. There are well-established protocol/processes to revoke such a pair and generating a new pair.
For these reasons, an improved security protocol is desired to minimize the problems in a shared symmetric key protocol particularly for use in a scalable/cross-platform authentication system.